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Summary 

A Fortran program has been written for use on an IBM 
PC/XT or AT or compatible microcomputer (personal 
computer, PC) that converts a column of ASCII-format 
numbers into a binary-format File suitable for interactive 
analysis on a Digital Equipment Corporation (DEC) computer 
running the VGS-5000 Enhanced Data Processing (EDP) 
software package. The incompatible floating-point number 
representations of the two computers were compared, and a 
subroutine was created to correctly store floating-point 
numbers on the IBM PC, which can be directly read by the 
DEC computer. Any file transfer protocol having provision 
for binary data can be used to transmit the resulting File from 
the PC to the DEC machine. The data File header required 
by the EDP programs for an x-ray photoelectron spectrum is 
also written to the File. The user is prompted for the relevant 
experimental parameters, which are then properly coded into 
the format used internally by all of the VGS-5000 series EDP 
packages. 

Introduction 

An increasing number of sophisticated surface analysis 
systems are today controlled by computers that provide the 
operator with not only an easier task in running the equipment 
but also, in some cases, with integral data analysis capabilities. 
The ability to perform the data analysis interactively with a 
color graphics display speeds the process considerably when 
compared with batch job processing. Interactive analysis also 
allows the researcher to watch for spurious data that might 
go undetected when some form of automatic spectrum 
processing is used. 

The commercial data analysis package acquired by our 
research group was a VGS-5000 system running the Enhanced 
Data Processing (EDP) software. This software can perform 
peak synthesis, peak deconvolution, background subtraction, 
peak area measurement, data smoothing, differentiation and 
integration, spike removal, and satellite subtraction, as well 
as provide spectrum overlays, montage plots, and expanded 
viewing areas on the graphics terminals. The desirability of 
“importing” data from other similar experimental systems 
quickly became apparent. In particular, we had an older x-ray 
photoelectron spectroscopy (XPS) system that could digitally 
store data but had only limited data analysis software. 


Additionally, in order to test the performance of the data 
analysis routines, a means of creating controlled test data Files 
was needed. This report details the methods used to create 
EDP-compatible Files from externally generated data. 

A recent publication (ref. 1) details the results of the 
Versailles Project on Advanced Materials and Standards 
(VAMAS) Surface Chemical Analysis group effort to produce 
the Standard Data Transfer Format. The need for a standard 
exchange format for surface analysis data is exemplified by 
the desirability of using a second computer to analyze data 
captured by a dissimilar computer. The VAMAS Standard 
Data Transfer Format uses only ASCII code characters (ref. 2) 
and provides for a wide range of surface analysis techniques. 
The type of information contained in the EDP file header 
closely parallels the VAMAS standards, although the information 
is stored in a more space-efficient binary form. Unfortunately, 
a program to convert ASCII format data to binary is not yet 
available for the EDP software. The program described herein 
is a limited start toward that goal for one analysis technique 
(XPS) and could be modified to parse for the VAMAS code 
words rather than requiring keyboard input of experimental 
parameter values. 


Methods 

Hardware and Communications 

The computer that was purchased to run our data analysis 
software was a multiterminal, multiuser system with eight 
RS-232C serial ports. It had no programming language other 
than the assembly language native to the machine. In order 
to import data, any of the unused serial ports could have been 
connected to a modem or, as was done, connected directly 
to another computer via a null-modem serial cable. Direct 
connection avoids the potential for unauthorized computer 
access over the telephone lines, and in our case allowed the 
second computer to be used as another data analysis 
workstation because the short serial cable permitted a higher 
communication speed than is typically possible over telephone 
lines. Painting a screen full of graphics usually involves many- 
more characters to be sent than does a simple display of text. 
The higher communication speed therefore made practical the 
use of graphics terminal emulation software on the second 
computer. A number of graphics terminal emulation programs 
exist for the IBM PC/XT or AT and compatible microcomputers 
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(personal computers, PC), depending upon the graphics display 
hardware present. Whether or not they have graphics capability, 
most terminal emulation programs come with built-in data 
transfer protocols such as Kermit and XMODEM. 

For file transfer, the set of public domain programs that 
implement the Kermit protocol has been chosen for use in our 
laboratory, in part because versions are available both for the 
Digital Equipment Corporation (DEC) PDP-1 1/73 running the 
Micro-RSX operating system as well as for the PC. 1 The 
protocol allows transmission of eight-bit binary (nontext) files, 
even over serial lines configured for seven-bit data. Although 
the Kermit program for the PC does not support emulation 
of DEC color graphics terminals and cannot be used with the 
EDP interactive data analysis routines, it does emulate the 
DEC VT102 terminal, which the Micro-RSX operating system 
recognizes. Additionally, all of the DEC color graphics terminal 
emulation programs known to the author do support file 
transfer via the Kermit protocol. If the PC were to be used 
as an interactive data analysis terminal, the Kermit protocol 
on the DEC machine would still be usable for file transfer. 
Other methods of binary file transfer, such as transfer over 
some form of local area network, can also be implemented, 
with potentially significant improvements in data transmission 
rate over that of a serial port. However, in most cases, the 
Kermit protocol should prove adequate. 

Language 

The Fortran language on the PC was chosen to reformat the 
external data for importation into the EDP software. Fortran 
remains a computer language familiar to most scientists and 
engineers and is available on microcomputers at many facilities. 
A Fortran compiler could be purchased for use on the DEC 
machine also. This would avoid the problem of incompatible 
floating-point number representations. In general, however, 
the prices of language compilers for small, single-user 
microcomputers are significantly less than those for multiuser 
computer systems, and a relatively simple, general-purpose 
subroutine solves the incompatible floating-point number 
problem. 

Input Files 

As written, the data-reformatting program uses an example 
data header file stored under the name TEMPLATE. XPS on 
the PC (see the appendix for an explanation of the data file 
header). An initial source for this file can be any EDP data 
file from an experiment similar to the type of data being imported. 
Downloading a binary data file from the DEC machine to the 


[ For information about Kermit documentation, updates, lists of current 
available versions, and ordering information, write to Kermit Distribution, 
Columbia University Center for Computing Activities, 612 West 1 15th Street, 
New York, NY 10025 (USA). 


PC can serve also as a first check to determine whether the 
data transfer protocol is functioning properly. If for some 
reason it is not possible to download this file, another 
alternative (strongly discouraged by the author) is to use the 
information about the header in the appendix and the 
DEBUG.COM program on the PC to create the initial 
TEMPLATE. XPS data header file. 

The input data file used by the program is no more than 
a text file in the form of a column of ASCII numbers, with 
each value followed by a carriage return. These can be the 
output of a data collection routine or can even be keyed in 
through the use of a program editor. By modifying the data- 
reading portion of this program, almost any input data format 
can be accommodated. For instance, the file from a spreadsheet 
“print to disk” operation could also be accepted. Once the 
PC has a value stored internally as a floating-point number, 
whether from text or even binary number input, the conversion 
from PC to DEC binary format is straightforward. As written, 
the program treats the first input file entry as the number of 
data values to follow in the file. The user is prompted for the 
rest of the spectrum parameters when the program is run. 

Formats 

Floating-Point Numbers 

For creating files to be read unaltered by computers of 
different manufacturers with different operating systems and 
machine architectures, the first discussion should be of numeric 
representation formats. How do the binary digits, or bits, stored 
in a binary data file correspond to the values used by a 
program? A cursory discussion of the ANSI/IEEE Standard 
754-1985 for 32-bit floating-point number representation 
(fig. 1) follows. 

The most significant (left-most) bit gives the sign, with a 
0 indicating a positive number and a 1 indicating a negative 
number. The next eight most significant bits are an exponential 
factor, or multiplier, for the fractional part of the number 
represented by the remaining 23 bits. In order to have both 
positive and negative exponents, the eight-bit exponent that 
is stored is offset by 127, which is approximately half of the 
maximum value an eight-bit number can have. The exponent 
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Byte 1 Byte 2 Byte 3 Byte 4 

ANSI/IEEE: Value «(-1)l s l * 2<l e l -127 ) * [1.mJ 

DEC: Value -(-1)^ * 2d e l" 128 ) * [o.im] 

Figure 1.— Thirty -two- bit floating-point number representations. Each “x” 
represents one binary digit, either a 0 or a 1 . Numbers enclosed in square 
brackets are in binary form. 
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factor can effectively range from 2~ 127 to 2 128 . In order to 
use the exponent, the value 127 (the offset) must first be sub- 
tracted from the value actually stored. The mantissa, or 
fractional part of the floating-point number, is stored in a 
“hidden bit normalization” form. The mantissa is normalized 
by shifting the magnitude of the fractional part and then adjusting 
the value of the exponent until the most significant binary digit 
of the mantissa is a 1. This preserves maximum accuracy in 
representing the fractional part of the number by preventing 
leading zeros. Since the first bit of every fraction is a 1 , there 
is no need to actually store that digit. This convention increases 
the accuracy by one bit. The leading bit is not assumed to be 
a 1 only when the exponent is 0. This corresponds to the 
smallest floating-point numbers that can be represented. There 
need not be concern about special cases for this discussion. 

The differences between the IEEE and DEC PDP-11 
floating-point representations are the offset used for the 
exponent and the assumed magnitude of the mantissa. DEC 
uses an exponent offset of 128 rather than 127, thereby giving 
the exponent a range from ^ _128 to 2 127 . This differs from 
the IEEE format by a factor of 2. The DEC format also 
assumes a mantissa of the form O.lxxx..., where each “x” 
represents one of the 23 least significant binary digits of the 
32-bit floating-point number (each “x” is either a 1 or a 0). 
The IEEE assumed representation is of the form 1 xxx. . . . The 
DEC format differs from the IEEE again by a factor of 2. In 
both representations, the leading 1 is assumed and need not 
be stored, leaving 23 bits to represent the rest of the mantissa, 
denoted here by x. In order to convert a number from the IEEE 
representation to the DEC form, both a shift in the implied 
mantissa value and an increase of the exponent must occur. 
Both changes can be accomplished by multiplying the IEEE 
representation by a factor of 4 to obtain the DEC representation. 

The final floating-point number issue that must be addressed 
is the manner in which the numbers are stored in a file. If 
the 32 bits of a floating-point number are divided into four 
groups of eight bits each, or bytes, the most significant (left- 
most) eight bits can be arbitrarily called “byte 1”; the next 
most significant eight bits (bits 23 through 16), “byte 2”; and 
so on (fig. 1). Apparently because of the internal architectures 
of the two types of machine, the most efficient method of 
storage for each machine involves a different byte ordering. 

For the Intel 80x86 processor-chip based machines (8086, 
8088, 80286, or 80386, i.e., IBM PC/XT or AT and compati- 
bles), the first byte sequentially stored in a file is byte 4, 
followed by byte 3, byte 2, and finally, byte I. This byte 
ordering is used in each of the languages checked by the 
author. 2 


^Binary floating-point number files from the following languages were 
available to the author: Lahey Fortran, Microsoft Fortran, Microsoft 
QuickBASIC 4.0, and Borland Turbo Pascal (on a PC with mathematic 
coprocessor chip installed). Turbo Pascal, in particular, may use its own 48-bit 


The DEC machine, originally based on a 16-bit bus architec- 
ture, reverses every pair of bytes, storing them sequentially 
in the order: byte 2, byte 1, byte 4, and finally, byte 3. The 
difference between the two types of machine requires only that 
the pair of bytes 2 and 1 be shifted in front of the pair of bytes 
4 and 3 for the change from 80x86 to PDP-1 1 byte ordering. 
In Fortran, an easy method of accomplishing the byte swap 
uses an EQUIVALENCE operation between a REALM 
variable and an INTEGERS variable array. The two 
INTEGER *2 values are exchanged and the resulting modified 
REALM variable can then be stored on disk. Because both 
machines reverse the byte order for two-byte numbers, 
standard 16-bit integers can be passed unaltered between the 
two types of computer. 3 

Output Files 

In order to be used with the EDP software, an external data 
file must not only present readable numbers, but must also 
incorporate any file headers or other information expected by 
the analyzing routines. The following discussion is a short 
overview of the data file structure written and read by the EDP 
software on the VGS-5000 series of systems. 

Files on the DEC PDP-1 1/73 computer are usually stored 
in units of “blocks,” each 512 bytes in size. Each EDP data 
file has at least a four-block information section ahead of the 
actual data. The header information is needed because data 
files from a number of different experimental techniques, as 
well as multiregion and depth profile data, can be analyzed 
with the EDP software. The files produced by the routine 
reported here are in the form of a single-spectral-region, 
binding-energy-scan XPS spectrum. Comments are included 
in the source code, which should allow easy expansion of the 
program to certain other types of data file. Each block of the 
file header is detailed byte by byte in the appendix. 

The first block of the file header provides general 
information about the data file, such as how many spectral 
regions are present and how large they are. The second block 
provides space for region names up to the maximum number 
of regions allowed, although only single-region files are 
created by this program. Up to three lines of descriptive 
comment can be stored in the third file header block. The 
fourth header block, describing the data immediately following 
it, contains information about the experimental technique and 


floating-point number representation on machines not equipped with the 
coprocessor chip. Therefore, care should be exercised if the algorithm 
presented herein is rewritten in Pascal. Fortran compilers not listed here 
presumably use the machine-efficient byte ordering called for by either an 
8087 or an 80287 coprocessor, whether a coprocessor chip is present or not. 
However, the byte order of a test file should be checked before trying to use 
this program unmodified with other Fortran compilers on a PC. 

^The program ASCITOVG is available from COSMIC. University of 
Georgia, Athens, GA. 
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conditions such as the type of scan, the range of the scan, the 
excitation source, and the analyzer mode. This header block 
would recur once for each spectral region in a multiregion file. 
It is located directly ahead of the data blocks that it describes 
and separates them from the data of preceding regions. The 
fifth and all subsequent blocks in a single-region file contain 
the four-byte data values, stored 128 to the block. 

The Fortran program itself can be described in terms of a 
few basic functions. After checking for the header file 
TEMPLATE. XPS in the PC default directory, the program 
prompts the user for input and output file names to use (with 
or without path names) and opens the files. The number of 
input points is read, and the minimum and maximum input 
values in the file are found. The user is then prompted for 
information such as the starting and ending scan energies, the 
electron analyzer pass energy, the excitation source, the dwell 
time, and the number of combined (integrated) scans making 
up the data. The user is also asked for the time and date that 
the data were collected and is allowed to enter descriptive 
comments that will appear in plots of the spectrum. The actual 
reformatting of the data is then performed to finish the process. 

Summary of Results 

The incompatible floating-point number representations of 
a personal computer (PC) and a Digital Equipment Corporation 
(DEC) computer were compared, and a Fortran subroutine 
was created to correctly store single-precision, floating-point 
numbers on the PC that can be directly read by DEC 
computers. A Fortran program using this subroutine was 
written on the PC to convert a column of ASCII-format 
numbers into a binary-format file suitable for interactive 
analysis with the VGS-5000 Enhanced Data Processing (EDP) 
software package. More difficult than the reformatting of 
floating-point numbers was the creation of the exact data file 


header required by the EDP programs for an x-ray photoelectron 
spectrum. Experiment parameters, entered by the program 
user, are coded into the header format used internally by all 
of the VGS-5000 series EDP packages. Whether for externally 
captured data or for user-generated test data, the files created 
by the program described here should be useful on any of the 
VGS-5000 series interactive analysis workstations. 

Interested VGS-5000 users may send the author a blank, 
formatted, 5.25-in. IBM PC/XT or AT compatible floppy 
diskette for a copy of the program source code, executable 
program file, and example header file. The program should 
also soon become available through the COSMIC software 
service operated for NASA by the University of Georgia (call 
(404) 542-3265 for further information). 
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APPENDIX-DESCRIPTION OF DATA FILE HEADER 


In the following description of the data file header, data 
values are presented in hexadecimal (base 16 numbers) form. 
All hexadecimal numbers are underlined for clarity. Each 
hexadecimal digit represents four bits, requiring then only a 
two-digit hexadecimal number for each byte. The following 
is a comparison of equal values in hexadecimal (base 16), 
decimal (base 10), octal (base 8), and binary (base 2) number 
representations: 


Hexadecimal: 

I 

2 

3 

4 

5 

6 

7 

8 

Decimal: 

1 

2 

3 

4 

5 

6 

7 

8 

Octal: 

l 

2 

3 

4 

5 

6 

7 

10 

Binary: 

0001 

0010 

0011 

0100 

0101 

0110 

01 1 1 

1000 

Hexadecimal: 

9 

A 

B 

c 

D 

E 

F 

10 

Decimal: 

9 

10 

11 

12 

13 

14 

15 

16 

Octal: 

11 

12 

13 

14 

15 

16 

17 

20 

Binary: 

1001 

1010 

101 1 

1100 

1101 

1110 

1111 

10000 


Sequentially, from the beginning of the data file: 


Block 1 

Bytes Description 

1-2 FF FF; two-byte integer, value always equals 

- 1 , Check_Word 1 

3-4 FF FF; two-byte integer, value always equals 

-1, Checks Word2 

5-6 01_ 00; two-byte integer, with value of 1 ; 

version number, This_Version 

7-8 03 00; two-byte integer, with value of 3; 

number of blocks in this file header, 
File_Header_Size 

9-20 00 00; six two-byte integers, each with value 

of 0, Spare_Array 

21-22 01_ 00; two-byte integer, with value of 1; 

number of spectral regions up to the 
maximum (32), always equals 1 as written by 
this program, No__of_Regions 

23-24 two-byte integer number giving the number of 
512-byte data blocks in the first region (128 
data values per block), Region_Size 

25-26 01 00; two-byte integer, value always equal to 

1 in this program; number of blocks in region 
descriptor, Region_Header_Size 

27-28 (M 00; two-byte integer, value always equal to 
1 in this program, Region_Header_Id 

29-34 repeat of bytes 23-28 but for second data 
region, all values equal to 0 for one-region 
file created by this program 


35-214 repeat of bytes 23-28 but for data regions 3 
through 32; all values equal to 0 for the one- 
region file created by this program 

215-216 (H 00; two-byte integer, value always equal to 
1 in this program; number of depths at which 
spectra exist, No_of_Levels 

217-218 01. 00; two-byte integer, value always equal to 

1 in this program, No_of_Stages 

Additional byte values as follows: 

219-220 31 00 

221-236 0200010026202020 AE 9CCA7F 00 00 

2E 87; first element of Index_Entry_Array 

237-252 03 ^)0 01 00 27 20 20 20 AE 9C 7F 00 00 

2E 87; second element of Index_Entry_Array 

253-254 04 00; beginning of third element in array 

255-256 two-byte integer giving the total number of 
512-byte data blocks in the entire file, 
including all regions, same as bytes 23 and 24 
above for the one-region files written by this 
program 

257-268 2[2ogioogi8ogioooooooi84 

269-284 ^mmwoo^woooqoooooooooo 
00 53 

285-476 repeat of bytes 269 to 284 twelve more times 

477-512 FF FF; repeated values of —1 

Block 2 

Bytes Description 

1-2 05 00; two-byte integer, value always equals 

5, identifies this as the Region Name 
Information block 

3-17 up to 15-byte-long region name for first 
region using standard ASCII characters, 
unused bytes equal to the ASCII “space” 
character, hexadecimal 20 

18-482 20; region names for regions 2 through 32, 

unused in this program, each 15 bytes in 
length, each byte equal to the ‘space’ 
character 

Additional byte values as follows: 

483-496 0 1_ Q!? 56 A2 40825053202020202020 

497-512 20 20 202020200100 21 202020AE9C 

CA7F 


5 



Block 3 


19-22 

four-byte REALM number, maximum data 

Bytes 

Description 


value in any channel of the spectrum, 

1-2 

02 00; two-byte integer, value always equals 


Y_Maximurn 


2, identifies an Information block 

23-26 

four-byte REAL *4 number, energy increment 

3-4 

two-byte integer, day of the month data taken 


between data points, X_Step 

5-6 

two-byte integer, day of the week data taken 

27 

01 ; one-byte integer, value always equals 1 in 
this program, indicates that the X-axis values 

7-8 

two-byte integer, month data taken 


are “binding energy”, X_Axis_Units 

9-10 

two-byte integer, year data taken 

28 

05; one-byte integer, value always equals 5 in 

11-12 

two-byte integer, hour of the day data taken, 
military format from 0 to 23 hours 


this program, indicates that the Y-axis values 
(the data) are “Counts” 

13-14 

two-byte integer, minutes data taken 


Note that values for the X- and Y-axis units 

15-16 

two-byte integer, seconds data taken 


are 

17-56 

first 40-byte comment line, standard ASCII 
characters, unused bytes equal to the “space” 
character, hexadecimal 20 


00 Kinetic_eV (kinetic energy in electron 
volts) 

01 Binding_eV (binding energy in electron 

57-96 

20; 40 ASCII “space” characters 


volts) 

02 AMU (atomic mass units) 

97-136 

second 40-byte comment line, standard ASCII 
characters, unused bytes equal to the “space” 
character, hexadecimal 20 


03 Seconds 

04 Degrees 

05 Counts 

137-176 

20; 40 ASCII “space” characters 


06 Count_eV_per_seconds 

177-216 

third 40-byte comment line, standard ASCII 


07 CPS (counts per second) 


characters, unused bytes equal to the ‘space 4 
character, hexadecimal 20 

29-30 

01 00; two-byte integer, value always equals 
1 in this program, No_of_Corresponding_Vars 

217-482 

20; ASCII “space” characters 

31-34 

four-byte REALM number, value equals 0 

Additional byte values as follows: 


here, Sensitivity_factor 

483-496 

01 00 56 A2 40 82 50 53 20 20 20 20 20 20 

35-38 

four-byte REAL *4 number, value equals 0 

497-512 

20 20 20 20 20 20 01 00 21 20 20 20 AE 9C 


here, Start_Profile_Range 

Block 4 

CA7F 

39-42 

43-64 

four-byte REALM number, value equals 0 
here, End_Profile_Range 

00 00; zero values 

Bytes 

Description 

65-68 

four-byte REALM number, gives the dwell 

1-2 

01 00; two-byte integer, value always equals 
1, identifies block as Data Header, occurs at 
beginning of each data region in multiregion 


time per channel during each scan, in 
milliseconds, Dwell_Time 


data file, occurs only once in data files 
written by this program 

69-70 

00 00; two-byte integer, value always equals 
0 in this program, Signal_to_Noise 

3-4 

00 00; two-byte integer, value always equals 
0 here, identifies data as a spectrum 

71-72 

two-byte integer, gives the number of scans 
summed to produce the data set, No_of_Scans 

5-6 

two-byte integer, gives the number of data 
points in the data set, Number_of_Channels 

73 

00; one-byte integer, value always equals 0 in 
this program, indicates that the number of 

7-10 

four-byte REAL*4 number, starting electron 
energy of spectrum, X_Start 


counts per channel were summed from scan to 
scan, Point_Repeat 

11-14 

four-byte REALM number, ending electron 
energy of spectrum, X_End 


Note that values for the mode of channel 
repetition are 

15-18 

four-byte REALM number, minimum data 
value in any channel of the spectrum, 
Y_Minimum 


00 Integrated 
(M Averaged 
02 PositionjSensitive 


6 


74 


75 


76 

77-80 

81-84 

85 


86 

87-90 

91-94 

95 


00; one-byte integer, value always equals 0 in 
this program, indicates that the data are XPS 
data, Type_of_Technique 

Note that values for the technique are 

00 XPS 

01 Auger 

02 UPS 

03 LEELS 

04 ISS 

05 SIMS 

00; one-byte integer, value always equals 0 in 
this program, indicates that the analyzer mode 
is constant analyzer energy (CAE), Analyzer. 
Mode 

Note that values for the analyzer mode are 

00 CAE (constant analyzer energy) 

01. CRR (constant retarding ratio) 

00 ; zero-value byte 

four-byte REAL *4 number, analyzer energy in 
CAE mode, in electron volts, Analyzer.Value 

four-byte REAL*4 number, work function of 
the analyzer, in electron volts from the 
vacuum level, Analyzer_Work_Function 

one-byte integer, value equals either 0 or 1 in 
this program, indicates the excitation source, 
Source.Type 

Note that values for the type of source are 

00 A1 

01 Mg 

02 Ag 

03 Au 

04 Zr 

05 Unknown.Source 

06 HeliumM 

07 Helium_2 

08 Electrons 

00 ; zero-value byte 

00; four-byte REAL *4 number, value always 
equals 0 in this program, Source.Strength 

four-byte REAL *4 number, energy of the 
excitation source in electron volts, 
Source.Energy 

00; one-byte integer, value always equals 0 in 
this program, indicates the type of signal 
collected, SignaLMode.Type 

Note that values for the types of signal are 

00 Pulse.Counting 
(H Differential 
02 Analogue 


96 

97-100 

101-104 

105-108 

109-112 

113-116 

117-120 

121-124 

125-128 

129-132 

133-136 

137-140 

141-155 

156-195 

196-235 

236 

237-244 

245-252 

253 


00; zero-value byte 

00; four-byte REALM number, value always 
equals 0 in this program, Modulation 

00; four-byte REALM number, value always 
equals 0 in this program, Analyzer_Polar_Angle 

00; four-byte REALM number, value always 
equals 0 in this program, Analyzer_Azimuth_ 
Angle 

00; four-byte REALM number, value always 
equals 0 in this program, Sample^Polar.Angle 

00; four-byte REALM number, value always 
equals 0 in this program, Sample.Azimuth. 
Angle 

00; four-byte REALM number, value always 
equals 0 in this program, Sample.Rotation. 
Angle 

00 ; four-byte REALM number, value always 
equals 0 in this program, Sample.X 

00; four-byte REALM number, value always 
equals 0 in this program, Sample.Y 

00; four-byte REALM number, value always 
equals 0 in this program, Sample.Z 

00; four-byte REALM number, value always 
equals 0 in this program, Target_Bias 

00 ; four-byte REALM number, value always 
equals 0 in this program, Sample.Charging 

up to 15-byte-long region name using standard 
ASCII characters, unused bytes equal to the 
ASCII “space’’ character, hexadecimal 20 

20 ; 40-byte-long ASCII character label, all 
bytes equal to the “space” character in this 
program, hexadecimal 20, Label 1 

20 ; 40-byte-long ASCII character label, all 
bytes equal to the “space” character in this 
program, hexadecimal 20, Label2 

00; zero-value byte 

00 ; two four-byte REAL *4 numbers, values 
always equal 0 in this program, Label Imposition 

00; two four-byte REALM numbers, values 
always equal 0 in this program, Label2_Position 

00; one-byte integer, value always equals 0 in 
this program, indicates the type of profile 
taken, Profile.Type 

Note that values for the types of profile are 

00 Non_Profile 

01 Cyclic.Etch.Time 

02 Continuous_Etch_Time 

03 Cyclic.Time 
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